<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>message_t</title>
<meta name="author" content="Philip Levis" />
<style type="text/css">

/*
:Author: David Goodger
:Contact: goodger@users.sourceforge.net
:date: $Date: 2009-02-03 23:07:32 $
:version: $Revision: 1.12 $
:copyright: This stylesheet has been placed in the public domain.

Default cascading style sheet for the HTML output of Docutils.
*/
body {
  font-family: Times;
  font-size: 16px;
}

.first {
  margin-top: 0 ! important }

.last {
  margin-bottom: 0 ! important }

.hidden {
  display: none }

a.toc-backref {
  text-decoration: none ;
  color: black }

blockquote.epigraph {
  margin: 2em 5em ; }

dd {
  margin-bottom: 0.5em }

div.abstract {
  margin: 2em 5em }

div.abstract p.topic-title {
  font-weight: bold ;
  text-align: center }

div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
  margin: 2em ;
  border: medium outset ;
  padding: 1em }

div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
  color: red ;
  font-weight: bold ;
  font-family: sans-serif }

div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
  font-weight: bold ;
  font-family: sans-serif }

div.dedication {
  margin: 2em 5em ;
  text-align: center ;
  font-style: italic }

div.dedication p.topic-title {
  font-weight: bold ;
  font-style: normal }

div.figure {
  margin-left: 2em }

div.footer, div.header {
  font-size: smaller }

div.line-block {
  display: block ;
  margin-top: 1em ;
  margin-bottom: 1em }

div.line-block div.line-block {
  margin-top: 0 ;
  margin-bottom: 0 ;
  margin-left: 1.5em }

div.sidebar {
  margin-left: 1em ;
  border: medium outset ;
  padding: 0em 1em ;
  background-color: #ffffee ;
  width: 40% ;
  float: right ;
  clear: right }

div.sidebar p.rubric {
  font-family: sans-serif ;
  font-size: medium }

div.system-messages {
  margin: 5em }

div.system-messages h1 {
  color: red }

div.system-message {
  border: medium outset ;
  padding: 1em }

div.system-message p.system-message-title {
  color: red ;
  font-weight: bold }

div.topic {
  margin: 2em }

h1 {
  font-family: Arial, sans-serif;
  font-size: 20px;
}

h1.title {
 text-align: center;
 font-size: 32px;
}

h2 {
 font-size: 16px;
 font-family: Arial, sans-serif;
}

h2.subtitle {
  text-align: center }

h3 {
 font-size: 12px;
 font-family: Arial, sans-serif;
}

hr {
  width: 75% }

ol.simple, ul.simple {
  margin-bottom: 1em }

ol.arabic {
  list-style: decimal }

ol.loweralpha {
  list-style: lower-alpha }

ol.upperalpha {
  list-style: upper-alpha }

ol.lowerroman {
  list-style: lower-roman }

ol.upperroman {
  list-style: upper-roman }

p.attribution {
  text-align: right ;
  margin-left: 50% }

p.caption {
  font-style: italic }

p.credits {
  font-style: italic ;
  font-size: smaller }

p.label {
  white-space: nowrap }

p.rubric {
  font-weight: bold ;
  font-size: larger ;
  color: maroon ;
  text-align: center }

p.sidebar-title {
  font-family: sans-serif ;
  font-weight: bold ;
  font-size: larger }

p.sidebar-subtitle {
  font-family: sans-serif ;
  font-weight: bold }

p.topic-title {
  font-weight: bold }

pre.address {
  margin-bottom: 0 ;
  margin-top: 0 ;
  font-family: serif ;
  font-size: 100% }

pre.line-block {
  font-family: serif ;
  font-size: 100% }

pre.literal-block, pre.doctest-block {
  margin-left: 2em ;
  margin-right: 2em ;
  background-color: #eeeeee;
  border-color: #000000;
  border-width: thin; 
  font-size: 14px
}

span.classifier {
  font-family: sans-serif ;
  font-style: oblique }

span.classifier-delimiter {
  font-family: sans-serif ;
  font-weight: bold }

span.interpreted {
  font-family: sans-serif }

span.option {
  white-space: nowrap }

span.option-argument {
  font-style: italic }

span.pre {
  white-space: pre }

span.problematic {
  color: red }

table {
  margin-top: 0.5em ;
  margin-bottom: 0.5em }

table.citation {
  border-left: solid thin gray ;
  padding-left: 0.5ex }

table.docinfo {
  margin: 2em 4em;
}

table.footnote {
  border-left: solid thin black ;
  padding-left: 0.5ex }

td, th {
  padding-left: 0.5em ;
  padding-right: 0.5em ;
  vertical-align: top }

th.docinfo-name, th.field-name {
  font-weight: bold ;
  text-align: left ;
  white-space: nowrap;
  }

h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
  font-size: 100% }

tt {}

ul.auto-toc {
  list-style-type: none }

</style>
</head>
<body>
<div class="document" id="message-t">
<h1 class="title">message_t</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">111</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Core Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>Final</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
<td>Philip Levis</td></tr>
</tbody>
</table>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">This memo documents a part of TinyOS for the TinyOS Community, and
requests discussion and suggestions for improvements.  Distribution
of this memo is unlimited. This memo is in full compliance with
TEP 1.</p>
</div>
<div class="section">
<h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>This memo covers the TinyOS 2.x message buffer abstraction, <tt class="docutils literal"><span class="pre">message_t</span></tt>.
It describes the message buffer design considerations, how and where
<tt class="docutils literal"><span class="pre">message_t</span></tt> is specified, and how data link layers should access it.
The major goal of <tt class="docutils literal"><span class="pre">message_t</span></tt> is to allow datagrams to be passed between
different link layers as a contiguous region of memory with zero copies.</p>
</div>
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>In TinyOS 1.x, a message buffer is a <tt class="docutils literal"><span class="pre">TOS_Msg</span></tt>. A buffer contains an
active message (AM) packet as well as packet metadata, such as timestamps,
acknowledgement bits, and signal strength if the packet was received.
<tt class="docutils literal"><span class="pre">TOS_Msg</span></tt> is a fixed size structure whose size is defined by the maximum
AM payload length (the default is 29 bytes). Fixed sized buffers allows
TinyOS 1.x to have zero-copy semantics: when a component receives a
buffer, rather than copy out the contents it can return a pointer
to a new buffer for the underlying layer to use for the next received
packet.</p>
<p>One issue that arises is what defines the <tt class="docutils literal"><span class="pre">TOS_Msg</span></tt> structure, as different
link layers may require different layouts. For example, 802.15.4 radio
hardware (such as the CC2420, used in the Telos and micaZ platforms)
may require 802.15.4 headers, while a software stack built on top of
byte radios (such as the CC1000, used in the mica2 platform) can specify
its own packet format. This means that <tt class="docutils literal"><span class="pre">TOS_Msg</span></tt> may be different on
different platforms.</p>
<p>The solution to this problem in TinyOS 1.x is for there to be a standard
definition of <tt class="docutils literal"><span class="pre">TOS_Msg</span></tt>, which a platform (e.g., the micaZ) can
redefine to match its radio. For example, a mica2 mote uses the standard
definition, which is:</p>
<pre class="literal-block">
typedef struct TOS_Msg {
  // The following fields are transmitted/received on the radio.
  uint16_t addr;
  uint8_t type;
  uint8_t group;
  uint8_t length;
  int8_t data[TOSH_DATA_LENGTH];
  uint16_t crc;

  // The following fields are not actually transmitted or received
  // on the radio! They are used for internal accounting only.
  // The reason they are in this structure is that the AM interface
  // requires them to be part of the TOS_Msg that is passed to
  // send/receive operations.
  uint16_t strength;
  uint8_t ack;
  uint16_t time;
  uint8_t sendSecurityMode;
  uint8_t receiveSecurityMode;
} TOS_Msg;
</pre>
<p>while on a mote with a CC2420 radio (e.g., micaZ), <tt class="docutils literal"><span class="pre">TOS_Msg</span></tt> is defined as:</p>
<pre class="literal-block">
typedef struct TOS_Msg {
  // The following fields are transmitted/received on the radio.
  uint8_t length;
  uint8_t fcfhi;
  uint8_t fcflo;
  uint8_t dsn;
  uint16_t destpan;
  uint16_t addr;
  uint8_t type;
  uint8_t group;
  int8_t data[TOSH_DATA_LENGTH];

  // The following fields are not actually transmitted or received
  // on the radio! They are used for internal accounting only.
  // The reason they are in this structure is that the AM interface
  // requires them to be part of the TOS_Msg that is passed to
  // send/receive operations.

  uint8_t strength;
  uint8_t lqi;
  bool crc;
  uint8_t ack;
  uint16_t time;
 } TOS_Msg;
</pre>
<p>There are two basic problems with this approach. First, exposing all of
the link layer fields leads components to directly access the packet
structure. This introduces dependencies between higher level components
and the structure layout. For example, many network services built on
top of data link layers care whether sent packets are acknowledged. They
therefore check the <tt class="docutils literal"><span class="pre">ack</span></tt> field of <tt class="docutils literal"><span class="pre">TOS_Msg</span></tt>. If a link layer does not
provide acknowledgements, it must still include the <tt class="docutils literal"><span class="pre">ack</span></tt> field
and always set it to 0, wasting a byte of RAM per buffer.</p>
<p>Second, this model does not easily support multiple data link layers.
Radio chip implementations assume that the fields they require are
defined in the structure and directly access them. If a platform
has two different link layers (e.g., a CC1000 <em>and</em> a CC2420 radio),
then a <tt class="docutils literal"><span class="pre">TOS_Msg</span></tt> needs to allocate the right amount of space for both
of their headers while allowing implementations to directly access
header fields. This is very difficult to do in C.</p>
<p>The <tt class="docutils literal"><span class="pre">data</span></tt> payload is especially problematic. Many
components refer to this field, so it must be at a fixed offset
from the beginning of the structure.
Depending on the underlying link layer, the header fields
preceding it might have different lengths, and packet-level radios
often require packets to be contiguous memory regions. Overall, these
complexities make specifying the format of <tt class="docutils literal"><span class="pre">TOS_Msg</span></tt> very difficult.</p>
<p>TinyOS has traditionally used statically sized packet buffers,
rather than more dynamic approaches, such as scatter-gather I/O
in UNIX sockets (see the man page for <tt class="docutils literal"><span class="pre">recv(2)</span></tt> for details).
TinyOS 2.x continues this approach.</p>
</div>
<div class="section">
<h1><a id="id1" name="id1">2. message_t</a></h1>
<p>In TinyOS 2.x, the standard message buffer is <tt class="docutils literal"><span class="pre">message_t</span></tt>. The
message_t structure is defined in <tt class="docutils literal"><span class="pre">tos/types/message.h</span></tt>:</p>
<pre class="literal-block">
typedef nx_struct message_t {
  nx_uint8_t header[sizeof(message_header_t)];
  nx_uint8_t data[TOSH_DATA_LENGTH];
  nx_uint8_t footer[sizeof(message_footer_t)];
  nx_uint8_t metadata[sizeof(message_metadata_t)];
} message_t;
</pre>
<p>This format keeps data at a fixed offset on a platform, which
is important when
passing a message buffer between two different link layers. If the
data payload were at different offsets for different link layers, then
passing a packet between two link layers would require a <tt class="docutils literal"><span class="pre">memmove(3)</span></tt>
operation (essentially, a copy). Unlike in TinyOS 1.x, where TOS_Msg
as explicitly an active messaging packet, message_t is a more general
data-link buffer. In practice, most data-link layers in TinyOS 2.x
provide active messaging, but it is possible for a non-AM stack to
share message_t with AM stacks.</p>
<p>The header, footer, and metadata formats are all opaque. Source code
cannot access fields directly. Instead, data-link layers provide access
to fields through nesC interfaces.  Section 3 discusses this in
greater depth.</p>
<p>Every link layer defines its header, footer, and metadata
structures. These structures MUST be external structs (<tt class="docutils literal"><span class="pre">nx_struct</span></tt>),
and all of their fields MUST be external types (<tt class="docutils literal"><span class="pre">nx_*</span></tt>), for two
reasons. First, external types ensure cross-platform compatibility <a class="footnote-reference" href="#id5" id="id2" name="id2">[1]</a>.
Second, it forces structures to be aligned on byte boundaries,
circumventing issues with the
alignment of packet buffers and field offsets within them. Metadata fields
must be nx_structs for when complete packets are forwarded to the serial
port in order to log traffic.
For example, the CC1000 radio implementation defines
its structures in <tt class="docutils literal"><span class="pre">CC1000Msg.h</span></tt>:</p>
<pre class="literal-block">
typedef nx_struct cc1000_header {
  nx_am_addr_t addr;
  nx_uint8_t length;
  nx_am_group_t group;
  nx_am_id_t type;
} cc1000_header_t;

typedef nx_struct cc1000_footer {
  nxle_uint16_t crc;
} cc1000_footer_t;

typedef nx_struct cc1000_metadata {
  nx_uint16_t strength;
  nx_uint8_t ack;
  nx_uint16_t time;
  nx_uint8_t sendSecurityMode;
  nx_uint8_t receiveSecurityMode;
} cc1000_metadata_t;
</pre>
<p>Each link layer defines its structures, but a <strong>platform</strong> is
responsible for defining <tt class="docutils literal"><span class="pre">message_header_t</span></tt>, <tt class="docutils literal"><span class="pre">message_footer_t</span></tt>,
and <tt class="docutils literal"><span class="pre">message_metadata_t</span></tt>. This is because a platform may have
multiple link layers, and so only it can resolve which structures are
needed. These definitions MUST be in a file in a platform directory
named <tt class="docutils literal"><span class="pre">platform_message.h</span></tt>. The mica2 platform, for example, has
two data link layers: the CC1000 radio and the TinyOS serial
stack <a class="footnote-reference" href="#id6" id="id3" name="id3">[2]</a>. The serial packet format does not have a footer
or metadata section. The <tt class="docutils literal"><span class="pre">platform_message.h</span></tt> of the mica2
looks like this:</p>
<pre class="literal-block">
typedef union message_header {
  cc1000_header_t cc1k;
  serial_header_t serial;
} message_header_t;

typedef union message_footer {
  cc1000_footer_t cc1k;
} message_footer_t;

typedef union message_metadata {
  cc1000_metadata cc1k;
} message_metadata_t;
</pre>
<p>For a more complex example, consider a fictional platform named
'megamica' that has both a CC1000 and a CC2420 radio. Its
<tt class="docutils literal"><span class="pre">platform_message.h</span></tt> would look like this:</p>
<pre class="literal-block">
typedef union mega_mica_header {
  cc1000_header_t cc1k;
  cc2420_header_t cc2420;
  serial_header_t serial;
} message_header_t;

typedef union mega_mica_footer {
  cc1000_footer_t cc1k;
  cc2420_footer_t cc2420;
} message_footer_t;

typedef union mega_mica_metadata {
  cc1000_metadata_t cc1k;
  cc2420_metadata_t cc2420;
} message__metadata_t;
</pre>
<p>If a platform has more than one link layer, it SHOULD define each of the
message_t fields to be a union of the underlying link layer structures.
This ensures that enough space is allocated for all underlying link layers.</p>
</div>
<div class="section">
<h1><a id="the-message-t-fields" name="the-message-t-fields">3. The message_t fields</a></h1>
<p>TinyOS 2.x components treat packets as abstract data types (ADTs),
rather than C structures, obtaining all of the traditional benefits
of this approach. First and foremost, clients of a packet layer
do not depend on particular field names or locations, allowing the
implementations to choose packet formats and make a variety of
optimizations.</p>
<p>Components above the basic data-link layer MUST always access
packet fields through interfaces.  A component that introduces
new packet fields SHOULD provide an interface to those that
are of interest to other components. These interfaces SHOULD take
the form of get/set operations that take and return values, rather
than offsts into the structure.</p>
<p>For example, active messages have an interface named <tt class="docutils literal"><span class="pre">AMPacket</span></tt>
which provides access commands to AM fields. In TinyOS 1.x, a
component would directly access <tt class="docutils literal"><span class="pre">TOS_Msg.addr</span></tt>; in TinyOS 2.x,
a component calls <tt class="docutils literal"><span class="pre">AMPacket.getAddress(msg)</span></tt>.
The most basic of these interfaces is Packet, which provides
access to a packet payload. TEP 116 describes common TinyOS
packet ADT interfaces <a class="footnote-reference" href="#id7" id="id4" name="id4">[3]</a>.</p>
<p>Link layer components MAY access packet fields differently than other
components, as they are aware of the actual packet format. They can
therefore implement the interfaces that provide access to the fields
for other components.</p>
<div class="section">
<h2><a id="headers" name="headers">3.1 Headers</a></h2>
<p>The message_t header field is an array of bytes whose size is
the size of a platform's union of data-link headers.
Because radio stacks often prefer packets to be stored contiguously,
the layout of a packet in memory does not necessarily reflect the
layout of its nesC structure.</p>
<p>A packet header MAY start somewhere besides the beginning of
the message_t. For example, consider the Telos platform:</p>
<pre class="literal-block">
typedef union message_header {
  cc2420_header_t cc2420;
  serial_header_t serial;
} message_header_t;
</pre>
<p>The CC2420 header is 11 bytes long, while the serial header is
5 bytes long. The serial header ends at the beginning of the
data payload, and so six padding bytes precede it. This figure
shows the layout of message_t, a 12-byte CC2420 packet, and
a 12-byte serial packet on the Telos platform:</p>
<pre class="literal-block">
            11 bytes         TOSH_DATA_LENGTH        7 bytes
          +-----------+-----------------------------+-------+
message_t |  header   |          data               | meta  |
          +-----------+-----------------------------+-------+

          +-----------+------------+                +-------+
CC2420    |  header   |   data     |                | meta  |
          +-----------+------------+                +-------+

                +-----+------------+
Serial          | hdr |   data     |
                +-----+------------+
</pre>
<p>Neither the CC2420 nor the serial stack has packet footers, and
the serial stack does not have any metadata.</p>
<p>The packet for a link layer does not necessarily start at the beginning
of the message_t. Instead, it starts at a negative offset from the
data field.  When a link layer component needs to read or write protocol
header fields, it MUST compute the location of the header as a negative
offset from the data field.  For example, the serial stack header has
active message fields, such as the AM type. The command that returns
the AM type, <tt class="docutils literal"><span class="pre">AMPacket.type()</span></tt>, looks like this:</p>
<pre class="literal-block">
serial_header_t* getHeader(message_t* msg) {
  return (serial_header_t*)(msg-&gt;data - sizeof(serial_header_t));
}
command am_id_t AMPacket.type(message_t* msg) {
  serial_header_t* hdr = getheader(msg);
  return hdr-&gt;type;
}
</pre>
<p>Because calculating the negative offset is a little bit unwieldy, the
serial stack uses the internal helper function getHeader(). Many
single-hop stacks follow this approach, as it is very likely
that nesC will inline the function, eliminating the possible overhead.
In most cases, the C compiler also compiles the call into a simple
memory offset load.</p>
<p>The following code is incorrect, as it directly casts the header field.
It is an example of what components MUST NOT do:</p>
<pre class="literal-block">
serial_header_t* getHeader(message_t* msg) {
  return (serial_header_t*)(msg-&gt;header);
}
</pre>
<p>In the case of Telos, for example, this would result in a packet
layout that looks like this:</p>
<pre class="literal-block">
            11 bytes         TOSH_DATA_LENGTH           7 bytes
          +-----------+-----------------------------+-------+
message_t |  header   |          data               | meta  |
          +-----------+-----------------------------+-------+

          +-----+     +------------+
Serial    | hdr |     |   data     |
          +-----+     +------------+
</pre>
</div>
<div class="section">
<h2><a id="data" name="data">3.2 Data</a></h2>
<p>The data field of message_t stores the single-hop packet payload.
It is TOSH_DATA_LENGTH bytes long. The default size is 28 bytes.
A TinyOS application can redefine TOSH_DATA_LENGTH at compile time
with a command-line option to ncc: <tt class="docutils literal"><span class="pre">-DTOSH_DATA_LENGTH=x</span></tt>.
Because this value can be reconfigured, it is possible that two
different versions of an application can have different MTU sizes.
If a packet layer receives a packet whose payload size is
longer than TOSH_DATA_LENGTH, it MUST discard the packet. As
headers are right justified to the beginning of the data payload,
the data payloads of all link layers on a platform start
at the same fixed offset from the beginning of the message buffer.</p>
</div>
<div class="section">
<h2><a id="footer" name="footer">3.3 Footer</a></h2>
<p>The message_footer_t field ensures that message_t has enough space to
store the footers for all underlying link layers when there are
MTU-sized packets. Like headers, footers are not necessarily stored
where the C structs indicate they are: instead, their placement is
implementation dependent. A single-hop layer MAY store the footer
contiguously with the data region. For short packets, this can mean
that the footer will actually be stored in the data field.</p>
</div>
<div class="section">
<h2><a id="metadata" name="metadata">3.4 Metadata</a></h2>
<p>The metadata field of message_t stores data that
a single-hop stack uses or collects does not transmit.
This mechanism allows packet layers to store per-packet
information such as RSSI or timestamps. For example, this is
the CC2420 metadata structure:</p>
<pre class="literal-block">
typedef nx_struct cc2420_metadata_t {
  nx_uint8_t tx_power;
  nx_uint8_t rssi;
  nx_uint8_t lqi;
  nx_bool crc;
  nx_bool ack;
  nx_uint16_t time;
} cc2420_metadata_t;
</pre>
</div>
<div class="section">
<h2><a id="variable-sized-structures" name="variable-sized-structures">3.5 Variable Sized Structures</a></h2>
<p>The message_t structure is optimized for packets with fixed-size
headers and footers. Variable-sized footers are generally easy
to implement. Variable-sized headers are a bit more difficult.
There are three general approaches that can be used.</p>
<p>If the underlying link hardware is byte-based, the header can
just be stored at the beginning of the message_t, giving it
a known offset. There may be padding between the header and
the data region, but assuming a byte-based send path this merely
requires adjusting the index.</p>
<p>If the underlying link hardware is packet-based, then the
protocol stack can either include metadata (e.g., in the
metadata structure) stating where the header begins or it
can place the header at a fixed position and use <tt class="docutils literal"><span class="pre">memmove(3)</span></tt>
on reception and transmit. In this latter case, on
reception the packet is continguously read into the message_t
beginning at the offset of the header structure. Once the
packet is completely received, the header can be decoded,
its length calculated, and the data region of the packet
can be moved to the <tt class="docutils literal"><span class="pre">data</span></tt> field. On transmission,
the opposite occurs: the data region (and footer if need
be) are moved to be contiguous with the header. Note that
on completion of transmission, they need to be moved back.
Alternatively, the radio stack can institute a single
copy at the botttom layer.</p>
</div>
</div>
<div class="section">
<h1><a id="implementation" name="implementation">4. Implementation</a></h1>
<p>The definition of message_t can be found in
<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/types/message.h</span></tt>.</p>
<p>The definition of the CC2420
message format can be found in <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/cc2420/CC2420.h</span></tt>.</p>
<p>The defintion of the CC1000 message format can be found in
<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/cc1000/CC1000Msg.h</span></tt>.</p>
<p>The definition
of the standard serial stack packet format can be found in
<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/lib/serial/Serial.h</span></tt></p>
<p>The definition of
the telos family packet format can be found in
<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/platform/telosa/platform_message.h</span></tt> and the micaz format can be found in
<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/platforms/micaz/platform_message.h</span></tt>.</p>
</div>
<div class="section">
<h1><a id="author-s-address" name="author-s-address">5. Author's Address</a></h1>
<div class="line-block">
<div class="line">Philip Levis</div>
<div class="line">358 Gates Hall</div>
<div class="line">Computer Science Laboratory</div>
<div class="line">Stanford University</div>
<div class="line">Stanford, CA 94305</div>
<div class="line"><br /></div>
<div class="line">phone - +1 650 725 9046</div>
<div class="line">email - <a class="reference" href="mailto:pal&#64;cs.stanford.edu">pal&#64;cs.stanford.edu</a></div>
</div>
</div>
<div class="section">
<h1><a id="citations" name="citations">6. Citations</a></h1>
<table class="docutils footnote" frame="void" id="id5" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id2" name="id5">[1]</a></td><td><a class="reference" href="http://nescc.sourceforge.net">nesC: A Programming Language for Deeply Embedded Networks.</a></td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id6" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id3" name="id6">[2]</a></td><td>TEP 113: Serial Communication.</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id7" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id4" name="id7">[3]</a></td><td>TEP 116: Packet Protocols.</td></tr>
</tbody>
</table>
</div>
</div>
</body>
</html>
